From reading the value propositions for these approaches, one might think that cloud-native goes in the opposite direction from DevOps. PaaS talks about “decoupling development from operations”. Google’s SRE team views itself as an operations organization, and sets rules governing its engagement with development teams. Serverless touts the benefit of not having to know or care about infrastructure, and seems to go hand-in-hand with NoOps, which seems to be about getting rid of operations altogether.

So what’s going on? Are silos all the rage again? Was DevOps just a dream from which we quickly awoke? Not when you look beneath the surface. Done properly, cloud-native isn’t about reinstating silos. It’s about turning them on their head. Traditional IT was the “department of no”. It sought to manage its challenges by asserting control, setting requirements, dictating the terms of engagement, and expecting its users to adapt to it rather than the other way around. “If you want a new server”, IT said, “you need to fill out these four confusing forms, then wait 20-40 days.” And so forth.

Cloud-native platforms and practices are taking hold because they offer capabilities that are both useful and usable. PaaS is able to decouple development from operations because it provides a single solution that addresses the needs of both perspectives: the ability to accelerate the delivery of code without degrading the scalability, resilience, security, or compliance of the environment in which that code runs. A healthy SRE practice doesn’t say “sorry, you’re out of luck and on your own until you figure out how to meet the error budget we’ve imposed on you.”; it proactively helps application teams understand the meaning of that budget and how to meet it. Serverless works because it narrows the impedance mismatch between operations-centric concepts such as “computers”, “networks”, “storage” and development-centric concepts such as “functions” and “methods”.

What all of these strategies have in common is their focus on helping applications teams accomplish their goals. In a delightful irony, ITIL, DevOps’ favorite bogeyman, actually got it right. ITIL v3 defines “service” as “facilitating desirable outcomes”. What do digital organizations want to accomplish? They want to deliver value to customers with as little friction as possible. They want to make that value available in a form that is scalable, resilient, and secure. Facilitating those outcomes is what cloud-native is all about.

Very few organizations are small enough to put the entirety of dev and ops into a single work-pod, take them all out to lunch together, or give them a single foosball table to share. Nearly every organization needs to figure out how to build a coherent whole out of multiple teams and disciplines. It was more than five years ago that I introduced the idea that empathy is the essence of DevOps. Empathy is the lubricant that makes systems thinking work. It’s what enables us to understand and thus facilitate others’ desired outcomes. Cloud-native only works when it reflects empathy with one’s customers; when it reflects a service-centered approach (“how can I help?”) rather than a product-centered approach (“here’s the thing I tipped up”). When decoupling provides service, it provides value, and thus is entirely compatible with the essence of DevOps.